One of the most important stages in the software development cycle is the debugging stage that occurs after a software product has shipped. This stage is important because the experiences of millions of users of the software product may be utilized during this stage to isolate program errors, identify frequently or infrequently used features, and to generally make the software product better. In order to capitalize on the body of user experience with the software product, however, it is necessary to obtain data from users and to route this data to the software developer.
Prior to the widespread adoption and use of the Internet, it was very difficult for software developers to obtain quality data regarding how a software product performs for a large number of users. Now, however, the Internet connects millions of users with the developers that create and debug the software they use. The Internet, therefore, allows data regarding the operation of a software product to be sent from a computer user to the developer of the product. The data may then be utilized by the developer to fix errors, also called “bugs,” in the program, to change the way the program operates by adding or removing features, and to otherwise improve the program. However, current systems for transmitting this data from a user to a software developer suffers from several drawbacks that reduce their effectiveness.
Current systems for reporting data regarding the operation of a software product generate event reports in response to the occurrence of an event within program code. For instance, an event report may be generated when an error occurs in the program code, when an unhandled exception is generated by the program code, when a particular line of code is encountered, or under other circumstances. Data that may assist the developer in understanding the event and in modifying the program code to ensure that it does not occur again is typically included in the event report. For instance, data describing the state of the computer when the event occurred may be included along with other data in the event report.
Although a large number of event reports regarding the occurrence of a particular event may be helpful to a developer in debugging a particular problem, too many reports for a particular problem may be unnecessary. For instance, if a software product is widely distributed and used by millions of users, a particular event occurring within the program may generate event reports from thousands of users. The thousands of event reports would be generated even though only the first ten may be useful to the developer. The rest of the users, other than the first ten, are then pointlessly inconvenienced by affecting the performance of their program and possibly by presenting them with an interrupting dialog box asking them to report the event. Previous systems for reporting the occurrence of events, however, do not have the ability to distinguish which types and particular occurrences of events should be reported.
Additionally, data collection is sometimes possible for an entire class of error conditions. The entire set of error conditions occurring within an application or suite of applications, for instance. However, if the development team responsible for the application is not interested in the entire set of error conditions, but rather only a few, previous systems are unable to report only the few reports that are interesting.
It is with respect to these considerations and others that the present invention has been made.